restore: Don't require docker for restore - #4615
Conversation
e753141 to
18d43d9
Compare
When running `azd restore` for a Docker based project, we were requiring that the docker tool itself was installed instead of whatever tool would be used by the actual source project. This has two implications: 1. If you didn't have the tool that was going to be invoked during `restore` installed (i.e. you didn't have `npm` for a node based project), we wouldn't detect the fact upfront and provide a nice error, we'd fail later when we tried to invoke the tool. 2. As of Azure#4567, we now require that the docker daemon be running to consider docker "installed" (which is reasonable for cases where we are going to invoke docker commands) and so `azd restore` now fails if you have a docker based project but are not running the docker deamon (as is the case in the macOS environment in CI). To fix both of these issues, I decided to accept the fact that ensuring the tools needed to do a restore is different from the other cases, and so the `ProjectManager` now has a `EnsureRestoreTools` method. As part of this, I also changed the `ProjectManager` such that `Initialize` no longer calls `EnsureAllTools` (which is logically did before, it had just inlined the logic) and audited all the callers to ensure that they were calling `EnsureAllTools` themselves or another `EnsureXXXTools` variant (doing so also made me realize a lot of the care we had put into some of the commands controling what sets of tools they checked for via these special Ensure methods was being undone by the implict call to `EnsureAllTools` from `Initialize`. Fixes Azure#4612
18d43d9 to
0498ab0
Compare
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
When running
azd restorefor a Docker based project, we were requiring that the docker tool itself was installed instead of whatever tool would be used by the actual source project. This has two implications:If you didn't have the tool that was going to be invoked during
restoreinstalled (i.e. you didn't havenpmfor a node based project), we wouldn't detect the fact upfront and provide a nice error, we'd fail later when we tried to invoke the tool.As of Fix azd issue #393 #4567, we now require that the docker daemon be running to consider docker "installed" (which is reasonable for cases where we are going to invoke docker commands) and so
azd restorenow fails if you have a docker based project but are not running the docker deamon (as is the case in the macOS environment in CI).To fix both of these issues, I decided to accept the fact that ensuring the tools needed to do a restore is different from the other cases, and so the
ProjectManagernow has aEnsureRestoreToolsmethod. As part of this, I also changed theProjectManagersuch thatInitializeno longer callsEnsureAllTools(which is logically did before, it had just inlined the logic) and audited all the callers to ensure that they were callingEnsureAllToolsthemselves or anotherEnsureXXXToolsvariant (doing so also made me realize a lot of the care we had put into some of the commands controling what sets of tools they checked for via these special Ensure methods was being undone by the implict call toEnsureAllToolsfromInitialize.Fixes #4612